IBIS Macromodel Task Group Meeting date: 30 September 2014 Members (asterisk for those attending): Altera: * David Banas ANSYS: * Dan Dvorscak * Curtis Clark Avago (LSI) Xingdong Dai Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan * Ken Willis Ericsson: Anders Ekholm Intel: Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy eASIC Marc Kowalski SiSoft: * Walter Katz * Todd Westerhoff * Mike LaBonte Synopsys Rita Horner Teraspeed Consulting Group: Scott McMorrow * Bob Ross (Note: Agilent has changed to Keysight) The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - Arpad will be traveling, may not be able to run the meeting next week. - Todd will be away also. - The meeting will still be held, Arpad will ask John to chair. -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Todd produce slides for co-optimization requirements discussion next week. - Not done. - Arpad to review IBIS spec for min max issues. - In progress. ------------- New Discussion: BIRD 147.1: - Walter showed a presentation "BCI Generic Protocol". - slide 2: - Walter: This was sent to Cadence for an opinion on whether it could be an IBIS approved protocol. - This uses both "Back-channel" and "Link training" so everyone understands. - Cadence said this could be a private protocol but not approved. - slide 3: - Walter: The evaluator path is blue here. - The TX must be able to tell the RX when it can't complete a request. - The protocol is yellow. - slide 4: - Walter this is a generic protocol. - slide 6: - Walter described a TX BCI parameter example with both indexes and coefficients. - Bob: Would those be reserved names? - Walter: The protocol defines these names. - David: This is a mode where TX DLLs have to be recompiled to do this? - Walter: Yes. - slide 7: - Walter: The AMI format is useful for documenting the protocol. - Calling it "InOut" is not quite compatible with AMI language. - This is documentation, the tools and DLLs do not read this. - slide 8: - Walter described an RX BCI parameter example. - Walter: It can send either indexes, coefficients, or increments. - slide 9: - Walter: The TX reports back how it handled the request. - It reports the coefficients actually used. - slide 10: - Walter: The RX may make more adjustments or switch to GetWave optimization flow. - An additional Init call might be made for statistical analysis using GetWave results. - There might be multiple time domain iterations. - Radek: This keeps the flow with the AMI description. - Walter: It means TX Init is re-entrant. - The ** pointer would initially be NULL. - Or we might want a different entry point for this. - slide 11: - Walter: This is not in BIRD 147. - It adds reserved Training_State in the AMI file. - The RX is much "smarter" than the TX. - There are also reserved Training_Protocol and Training_Pattern parameters. - slide 11: - Walter: This was the reply from Cadence. - slide 12: - Walter: A number of vendors agree the TX is very general purpose. - RX buffers report the eye at the decision point. - The logic to search the tap solution space is not clear. - IP providers may hesitate to reveal their secret sauce. - slide 6: - David: Why can't this be communicated by AMI file? - Walter: It could be, but the RX needs to have this information. - They would be AMI reserved parameters. - New parameters are not likely soon, but would required new reserved parameters. - Radek: Why would this not require recompiling the TX? - David: It doesn't change. Once in the AMI file I am done. - Walter: It could be in AMI but we want to be able to dynamically report tap settings. - That would require recompilation. - David: You proposed that only the range needs to be known. - Walter: That was Init training, not GetWave training. - TX models can have integer parameters for each tap. - We have to tell the EDA tool which tap is which. - The tool would get response after changing settings. - David: Existing TX models could not participate in GetWave training. - But they could participate in Init training. - Ambrish: BIRD 147 does not go there, but another BIRD could. - slide 14: - Walter: Another BIRD could be combined with this. - We still have to say which tap is which. - The purpose here is to propose something that is compliant with BIRD 147. - It would allow TXs and RXs to work together. - Ken: You can have private protocols, but it doesn't have to be part of this BIRD. - Todd: Cadence seems to be reversing position. - The question is if we can define parameters beyond what the BIRD defines. - We asked if a "framis" could be defined in a "ibis_" standard BCI file. - It could be a jitter number, anything. - Ambrish: The BCI file can have what the committee approves. - Walter: Ambrish should explain the last sentence on slide 12. - It prohibits "generic" parameters. - Ambrish: It has to belong to some existing protocol. - Todd: What on slide 6 is not eligible for standardization? - Ambrish: Which protocol is it? - Todd: Who decides what is industry standard? - Only approved industry bodies are eligible. - Ken: If you make your own I still expect any compliant tool to work with the models. - Todd: If a handful of silicon vendors decide on a protocol can that be standard? - Ambrish: Why does it need to be standard? - Todd: Once we agree, we like a stamp of approval. - Ambrish: When the time is right you can ask an organization to standardize it. - John: It might not correspond to what any hardware does. - Todd: Ambrish, you are saying yes, it would be eligible for standardization. - Ambrish: The intention was to call only IEEE protocols standard. - Todd: That should be in the BIRD, but it might sink it. - Ken: Industry standard means it is published for global use. - Arpad: What if IEEE came up with a generic standard? - Todd: The question is if 3 or 4 companies could create a standard BCI by their own agreement. - There should be a yes or no answer. - Ken: Where would the new parameters be? - Walter: It is all protocol specific in this example. - John: BIRD 147 gives List parameters, but it really would be a value in the end. - Walter: BIRD 147 is confusing on that. - Ambrish: Disagree that it is confusing. - Todd: We need BCI files to be standardized because our customers will want that. - John: The first issue is what is allowed in BIRD 147. - We need to talk about doing both modes in the same model. - That is not clear in the current BIRD. - Ken: A legal but non-standard BCI file should work in any compliant tool. - We will respond to Todd's question. ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives